Mt Xia: Technical Consulting Group

Business Continuity / Disaster Recovery / High Availability
Data Center Automation / Audit Response / Audit Compliance

Additional documents of interest

  • Successful Business Continuity - Part 1 - Users and Groups
    This article was published in the April 2005 issue of AIX Update magazine and discusses system administration needs and requirements oriented around users and groups. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters, such as user names, group names, UID and GID numbers.
  • Successful Business Continuity - Part 2 - Machine and Host Names
    This article was published in the May 2005 issue of AIX Update magazine and discusses naming structures for machines, systems, adapters, and aliases. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters.
  • Successful Business Continuity - Part 3 - Volume Names
    This article was published in the December 2005 issue of AIX Update magazine and discusses naming structures for volume groups, logical volumes, log logical volumes, directory mount points, etc. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters.
  • Successful Business Continuity - Part 4 - MQ Series, Startup/Shutdown Scripts, Error Processing
    This article was published in the April 2006 issue of AIX Update magazine and discusses how to implement AIX in an environment dedicated to business continuity. The topic of this article is the assignment of MQ Series queue names and aliases, resource group startup and shutdown script names (Application startup/shutdown script names), error logging, and error notification.
  • Successful Business Continuity - Part 5 - Miscellaneous topics
    This article was published in the August 2006 issue of AIX Update magazine and discusses how to implement AIX in an environment dedicated to business continuity. A variety of topics is discussed in this article including automated documentation generation and management.
  • Automated Microcode Management System
    One of the most difficult administration tasks in an AIX environment is attempting to keep the firmware and microcode up-to-date. Mt Xia has devised an automated method of gathering the Microcode information, determining which microcode needs to be updated, generating reports, and uploading the required microcode updates to each individual system.
  • Calculating the size of a Virtual Processor
    This document describes the algorithms used to calculate the size of a virtual processor when using shared processors in an LPAR. The IBM documentation describes how to calculate CPU utilization, NOT how to size for configuration, this document clarifies this process. A description of the HMC input fields for the processor tab is included.
  • Basics of Partition Load Manager Setup
    This presentation was provided by Ron Barker from IBM regarding the PLM Basic setup.
  • ppt
  • pdf
  • This document describes the algorithms used to calculate the size of a virtual processor in a shared processor environment using the Power5 architecture. The IBM documentation does not fully explain this concept and this document attempts to clarify this issue.

    When defining an LPAR through the HMC for the Power5 architecture, the type of processors assigned to the LPAR must be defined. The possible choices for this are: Dedicated and Shared. If "Shared" is selected, the following input fields are presented:

    Processing mode
    Dedicated
    Shared


    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:


    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    When entering "shared" mode processors, the "Processing units" input fields define the total amount of processing units that will be allocated to all virtual processors. This translates to the following algorithm:

    Algorithm:

    Vs = Pu / Vn

    Rules:

    1.00 Pu = 1 full power5 physical processor
    Pu < Pt
    Vn <= 64

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR
    Pt = Total number of physical processors in frame


    As an example of using this algorithm:

    Processing mode
    Dedicated
    Shared


    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:


    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    These values would allocate "0.5" physical processing units to the LPAR and "2" virtual processors. The size of each virtual processor would be "0.25" physical processing units.

    Algorithm:

    Vs = Pu / Vn
    Vs = 0.5 / 2
    Vs = 0.25

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR


    Another example using this algorithm:

    Processing mode
    Dedicated
    Shared


    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:


    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    These values would allocate "2.5" physical processing units to the LPAR and "5" virtual processors. The size of each virtual processor would be "0.50" physical processing units.

    Algorithm:

    Vs = Pu / Vn
    Vs = 2.5 / 5
    Vs = 0.50

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR


    A final example illustrating how the EGATE Proof of Concept LPAR's were configured:

    Processing mode
    Dedicated
    Shared


    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:


    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    In this example, if the desired number of physical processing units was allocated to the LPAR, "3.0" physical processing units would be allocated to the LPAR and "6" virtual processors. The size of each virtual processor would be "0.50" physical processing units.

    Algorithm:

    Vs = Pu / Vn
    Vs = 3.0 / 6
    Vs = 0.50

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR

    -
    Virtual Processor Size
    -
     


    FREE Domain Registration
    included with Web Site Hosting
    Tools, Social Networking, Blog

    www.siteox.com

    Business Web Site Hosting
    $3.99 / month includes Tools,
    Shopping Cart, Site Builder

    www.siteox.com